This task is part of the network policy configuration workflow. Use this task to configure and manage the cryptographic keys used to encrypt Wi-Fi traffic during the four-way handshake authentication process between an AP and clients, manage and set up Pairwise Transient Keys.
Setting | Description |
---|---|
Protected Management Frames | |
802.11w | Toggle 802.11w to ON to prevent forgery and retransmission of management frames. |
Use of 802.11w is | If you select a WPA3 level of security,
802.11w is enabled by default at a Mandatory level. The menu
and check box appear dimmed. If you select a WPA3 level of security with Transition Mode enabled, 802.11w will be enabled as Optional. If you select WPA2 level of security, 802.11w is disabled by default, with option to enable. |
Use 802.11w protection for broadcasts/multicasts | |
Advanced Authentication Options | |
Generate new Group Master Key (GMK) after | Type the time interval, after which the system generates
a new GMK. Select the unit of time (seconds, minutes, hours,
or days) from the list. The GMK is a large random number that an Extreme Networks device chooses. From the GMK, the device derives a GTK (Group Temporal Key), which it then sends to all associated clients within EPOL-key messages. The Extreme Networks device and clients use the GTK to encrypt and decrypt broadcast or multicast traffic transmitted between themselves. |
Generate New Group Temporal Key (GTK) after | Type the time interval, after which the system generates
a new GTK. Select the unit of time (seconds, minutes, hours,
or days) from the list. The wireless client and Extreme Networks device use a GTK to encrypt to and decrypt broadcast and multicast traffic transmitted between themselves. A GTK is a temporal key that an Extreme Networks device derives from a GMK (Group Master Key) by performing a cryptographic hash on the concatenation of the GMK, a nonce, and the MAC address of the Extreme Networks device. The Extreme Networks device then sends the GTK to all associated clients within EAPOL-Key messages. |
GTK Timeout Period | Type the time interval (in Milliseconds) that the device
waits for client replies during the handshake process. To accommodate clients that have shorter or longer timeout values, you can change this to a value from 100 (the standard timeout value) to a maximum of 8000 milliseconds. |
Number of GTK Retries | Type the maximum number of times the device will retry sending GTK messages. |
Generate a new Pairwise Transient Key (PTK) after | Select to enable PTK rekeying, and enter a value between
10 and 50,000,000 seconds (~231 days). If you enable PTK rekeying, an interval between 2 and 10 minutes (120 and 600 seconds) is the best practice recommendation, which is short enough to thwart the known TKIP exploit. Enable this option only if you know that the clients using the SSID support it. In addition, you might need to configure PTK rekeying on the clients. Note: There is a flaw in TKIP that allows an attacker to
decrypt unicast packets sent from an access point to
a wireless client, and then send the client-forged
packets, possibly with the purpose of poisoning ARP
or DNS caches. If you cannot transition to
AES-CCMP—which is not susceptible to this attack—you
can mitigate attacks against TKIP-encrypted data by
setting the PTK (pairwise transient key) to rekey at
short intervals.
|
PTK timeout period | Type the interval (in Milliseconds) that the device waits
for client replies during the four-way handshake in which
they derive a PTK for encrypting and decrypting unicast
traffic. To accommodate clients that have shorter or longer timeout values, you can change the value from 100 milliseconds (the standard timeout value) to a maximum of 8000 milliseconds. |
Number of PTK retries | Type the maximum number of times the device will retry sending PTK messages. |
Replay window | Type a window size, within which the device accepts
replies to previously sent messages during four-way
handshakes. 0 indicates that the device does not accept any messages other than a reply to the last message that it sent. You might want to accept replies to previously sent messages if there are clients that reply more slowly than the device retries sending it messages. |
Local TKIP Countermeasure | (Available only when the encryption method is Auto-TKIP
or CCMP (AES) or TKIP) Select to enable the deauthentication of all clients when the local device detects message integrity check failures during TKIP operations. If one key fails an integrity check, the discovery of such a failure suggests that other keys in current use might also be compromised. The cautious security stance is to deauthenticate all clients and stop using all existing keys immediately. When clients reauthenticate, they use newly generated pairwise and group primary and temporal keys. If this feature is disabled, the device continues to use existing keys and maintain currently connected clients after detecting MIC failures. |
Remote TKIP Countermeasure | (Available only when the encryption method is Auto-TKIP
or CCMP (AES) or TKIP) Select to deauthenticate all previously authenticated clients when a client reports MIC failures during TKIP operations. The distinction between the local and remote countermeasure options is where the discovery occurs:
|
Enable to refresh the GTK only when the rekey period elapses. | To disable GTK refresh when either the rekey period elapses or a client disassociates from the SSID, clear the check box. |